1. Field of the Invention
This invention relates generally to the field of data processing systems. More particularly, the invention relates to an improved system and method for monitoring and certifying the performance of object-oriented applications such as Java applications.
2. Background
The physical memory on any computing system is a limited resource. No matter how fast computing systems become, they always depend upon a finite amount of memory in which to run their software applications. As a result, software developers should consider this resource when writing and developing software applications.
The Java programming language differs from many traditional programming languages (e.g., C/C++) by the way in which memory is allocated and deallocated. In languages like C/C++, memory is explicitly allocated and deallocated by the application programmer/developer. This can greatly increase the time spent by programmers in tracking down coding defects in regards to deallocating memory.
By contrast, the Java runtime environment (i.e., Java virtual machine) provides a built-in mechanism for allocating and deallocating memory. In Java, memory is allocated to objects. The Java virtual machine (hereinafter “VM”) automatically handles the amount and allocation of memory upon an object's creation. The Java runtime environment employs a “garbage collector” (hereinafter “GC”) to reclaim the memory allocated to an object once the GC determines that the object is no longer accessible (e.g., referenced or linked by any other objects). When objects in a Java application are no longer referenced, the heap space the object occupied must be recycled so that the space becomes available for subsequently-created objects.
One problem, which may result from the garbage collection process is referred to as a “memory leak.” A memory leak can occur when a program (or in the case of Java, the VM) allocates memory to an object but never (or only partially) deallocates the memory when the object is no longer needed. As a result, a continually increasing block of memory may be allocated to the object, eventually resulting in an “Out of Memory” (hereinafter “OOM”) error.
Memory leaks are of particular concern on Java-based systems (e.g., J2EE platforms) which are meant to run 24 hours a day, 7 days a week. In this case, memory leaks, even seemingly insignificant ones, can become a major problem. Even the smallest memory leak in code that runs 24/7 may eventually cause an “OOM” error, which can bring down the VM and its applications.
Knowing how to track down memory leaks is essential to solid program design. There are many performance and/or debugging tools that are used to monitor and examine software applications to determine resource consumption as these applications are executing within the Java runtime environment. For example, a profiling tool may identify the most frequently executed methods and objects created in an application. Such a tool may also identify those objects which have the most memory allocated to them.
Another type of software performance and debugging tool is a “tracer.” Tracers use different techniques to provide information indicating the execution flows for a running program. One technique keeps track of particular sequences of instructions by logging certain events as they occur. For example, a trace tool may log every entry into, and every exit from, a module, subroutine, method, function, or system component. Typically, a time-stamped record is produced for each such event. Corresponding pairs of records similar to entry-exit records also are used to trace execution of arbitrary code segments, starting and completing I/O or data transmission, and for many other events of interest.
An important aspect of many tracer and/or profiling tools is memory leak detection. Many tools in the market are capable of such detection, but only in limited ways. Many tools in the prior art of capable of informing the developer where memory leaks occur, but only in the sense of what objects are causing the problem. However this information can be of little use to a developer if the underlying code lines or classes that created the objects are not identified. This leaves developers with often-insurmountable amounts of code to peruse through to find the specific class and method calls, etc, causing the problem. Further, although prior tools provide statistics on the memory allocation for all objects within a running application, such information may not be useful for an application that comprises 1000s of objects.
Therefore, it would be advantageous to provide a method and system for accurate memory leak detection in an object-oriented environment. In particular, it would be advantageous to allow such a system to automatically analyze the output provided, so as to reduce the manual analysis required by developers, especially if the returned information includes massive amounts of data which would otherwise be manually reviewed.